<header>
<h1>資料建置</h1>
</header>

<figure>
<object data="_files/data.svg" width="400"></object>
<figcaption>笈成資料建置流程圖</figcaption>
</figure>

<p>上圖為笈成的資料建置之大致流程，茲說明如下。</p>

<p>首先尋找最佳品質的可用電子文本。笈成目前收錄文本主要來源包括行政院衛生署中醫藥委員會建置之82部典籍、醫籍650文本、<a href="http://www.zygby.com">中醫瑰寶苑</a>網站之651~699文本、《漢典》之31部電子書、永諸藏書數十部、及其他網路文本，格式有TXT、DOC(X)、PDF、HTML等，詳見<a href="reference.html">參考資源</a>。</p>

<p>取得文本後，將電子文本轉置為HTML5格式的笈成文本，而後持續以程式處理、人工校對、差異比對等方式改進「笈成資料原始檔」（即笈成文本與共用網頁模版）的品質。</p>

<p>製作「笈成站台產生器」，可將笈成資料原始檔輸出為靜態網頁，以便發布於大部分伺服器環境。</p>

<p>中醫笈成網站即是將前述靜態網頁同步發布至伺服器，並加上其他站台輔助程式提供進階功能，例如自動轉換缺字的<a href="https://jicheng.tw/hanzi">笈成檢字系統</a>。將本地資料同步到伺服器的工具很多，如rsync及FreeFileSync皆可，本站主要使用rsync。</p>

<p><a href="https://gitlab.com/jicheng/jc.data">笈成資料原始檔</a>、<a href="https://gitlab.com/jicheng/jc.ssg">笈成站台產生器</a>皆以<a href="https://git-scm.com/">Git</a>做版本控管，並發布於<a href="https://gitlab.com/jicheng">GitLab</a>供開放協作。</p>


<h2>實用工具</h2>

<h3 id="git">Git</h3>

<p>我們主要使用<a href="https://git-scm.com/">Git</a>作為版本控制系統。使用版本控制系統的目的在於記錄每次修訂，以便在發生錯誤或有疑義時可追溯及還原。Git使用特殊的壓縮格式儲存資料，可節省大量儲存空間。按我們實際使用情形，儲存50000個修訂版本大約只需要最新版本資料的7倍空間。</p>

<p>除此之外，Git還支援版本線的分支、合併、移植、重新定基等進階功能，對於整理資料及多人協作亦大有助益。</p>

<p>Git為命令列介面，功能強大，但不易上手，可額外安裝圖形介面以利上手及提高一些基本操作的效率。Windows作業系統可使用<a href="https://tortoisegit.org/">TortoiseGit</a>，跨平台使用者可考慮<a href="https://www.sourcetreeapp.com/">SourceTree</a>等圖形介面。</p>

<figure>
<a href="_files/git1.jpg"><img src="_files/git1.jpg" width="400" alt=""></a>
<figcaption>TortoiseGit版本總覽畫面</figcaption>
</figure>

<figure>
<a href="_files/git2.jpg"><img src="_files/git2.jpg" width="400" alt=""></a>
<figcaption>TortoiseGit特定版本之檔案異動總覽畫面</figcaption>
</figure>

<h3 id="winmerge">WinMerge</h3>

<p><a href="https://winmerge.org/">WinMerge</a>主要用於文字檔的差異比對，介面完善易用，可單獨使用或整合Git圖形介面使用。</p>

<figure>
<a href="_files/winmerge1.png"><img src="_files/winmerge1.png" width="400" alt=""></a>
<figcaption>WinMerge差異比對畫面</figcaption>
</figure>

<div class="note">
<p>WinMerge早年開發曾陷入停滯，有獨立開發者建立了分叉版本<a href="https://github.com/datadiode/winmerge2011">WinMerge2011</a>（<a href="https://github.com/datadiode/winmerge2011/releases">安裝程式下載頁面</a>），並改善了許多問題。近年WinMerge開發轉趨積極，新版易用性已改善許多。</p>
<p>我們初步比較WinMerge (2.16.14.0)及WinMerge2011 (0.2011.211.170)，WinMerge支援三方合併等進階功能，但載入及操作反應較慢，且Unicode補充平面（SMP）的字元有時無法正常顯示。建議一般使用WinMerge2011，需要進階功能才用WinMerge。</p>
</div>

<h3 id="npp">Notepad++</h3>

<p><a href="https://notepad-plus-plus.org/downloads/">Notepad++</a>是國人開發的純文字編輯軟體，提供完善的純文字編輯功能，且有語法標示、自動補完、正規表示式搜尋／取代、多檔案搜尋／取代等功能，執行速度也很快，一般可完全取代Windows內建的記事本。</p>

<figure>
<a href="_files/npp1.png"><img src="_files/npp1.png" width="400" alt=""></a>
<figcaption>Notepad++只須幾個按鍵就能對大量檔案做尋找／取代</figcaption>
</figure>


<h2>示例：如何利用上述工具快速提高資料品質</h2>

<p>許多中醫數位文本最初是由中國建立，而後轉為繁體中文，或有經過校對，但錯誤仍所在多有。假設我們發現許多已收錄的文本有錯誤的簡轉繁「炒松」（應為「炒鬆」）……。</p>

<ol>
<li>用Git將目前版本記錄下來，假設為版本A。</li>
<li>用Notepad++的「在檔案中尋找/取代」功能，指定將資料目錄下所有「*.html」檔案的「炒松」取代為「炒鬆」。</li>
<li>將更動提交為新版本B。可在提交訊息註明為全自動修改，並記錄使用的尋找及取代條件，以利事後追查。</li>
<li>比對所有更動的文字，檢查是否有錯誤。可用圖形介面TortoiseGit和WinMerge列出所有被更動的檔案，逐一進入比對有差異處，亦可在命令列用「<code>git diff</code>」列出差異摘要逐一瀏覽。</li>
<li>若發現散在的錯誤，則手工修訂之。</li>
<li>若發現大量有規律的錯誤，例如多處「炒松子」被誤改為「炒鬆子」、「炒松节」被誤改為「炒鬆節」，則退回版本A，修改條件再試一次，如此例可改為尋找<a href="regex.html">正規表示式</a>「<code>炒松(?!子|节)</code>」取代為「炒鬆」，然後再提交為新版本B2。
  <ul>
  <li>就此例而言，亦可在版本B對所有檔案做「炒鬆子」取代為「炒松子」、「炒鬆節」取代為「炒松節」之操作再提交為新版本。最佳做法視具體情況而定。</li>
  <li>若在執行6.之前已做了一些5.的修訂，可將已做的修訂先提交為新版本C，按步驟6.退回版本A，更改條件，重新取代，提交為新版本B3，再移植C的修訂（<code>git cherry-pick C</code>）即可。</li>
  </ul>
</li>
<li>重複上述步驟，直至確認被更動的內容無誤，即完成此次的修訂工程。</li>
</ol>

<p>簡而言之，即是<strong>利用機器處理大量重複、類似的問題</strong>，再<strong>藉由差異比對找出剩餘的少量問題</strong>人工修正，即可快速提高資料的整體品質。</p>


<h2>附：為何沒有選擇維基文庫？</h2>

<p>維基文庫是開放自由編輯的古籍資料庫，與維基百科一樣是用MediaWiki架設。我們當初曾考慮過在上面整理資料，但實際操作後發現一些限制：</p>

<ul>
<li>維基內建語法無法滿足語義化整理古籍資料的需求：維基文庫雖允許自訂模版，但模版語法仍有侷限，且模版需調用模版頁面，導致依賴整個伺服器環境，一旦脫離伺服器，撰寫工具解析及處理內容即相當困難。按此，在維基文庫上很難做到如目前典籍檢索器強大的檢索功能。</li>
<li>維基文庫難以有效利用資訊技術做大規模修改：因資料皆在伺服器上，且維基文庫為防止破壞訂下許多限制，撰寫機器人修改文本曠力費時，操作速度也慢。一般機器人約15秒編輯一個頁面，若資料有3萬頁，須125小時才能完成；而前述本地檔案尋找取代的方式，一般只要10秒至1分鐘即可竟功。</li>
<li>基於頁面而非整個資料庫的版本控制不利復原：MediaWiki的版本控制是針對個別頁面，雖有其優點，但整體而言不如Git針對整個版本庫的版本控制靈活。例如Git可以把「所有頁面將X修正為Y」記錄為一個版本，而MediaWiki會把對每個頁面的編輯分別記錄，產生成千上萬個修訂，導致查閱不便。若大規模編輯出錯，MediaWiki要復原所有被破壞的頁面並不容易（非管理者只能再寫個機器人，以同樣慢的速度逐頁編輯復原）；而用Git只要一個簡單指令即可完全復原。</li>
<li>缺少私人空間：MediaWiki是完全公開的系統，設計上未提供私人空間，使用者想嘗試任何操作都會立即留下永久的公開記錄，這種特性讓一些使用者望而卻步。MediaWiki雖然支援即時線上編修，但行動設備編修文本的效率其實不高。相較之下，基於Git的流程讓使用者能在自己的設備，用最習慣順手的純文字編輯器，寫無限次草稿，做無限次程式操作，還能重整版本記錄，直至一切妥當再發布上線，更為靈活高效。</li>
<li>此外，維基文庫系統龐大，人員眾多，要做大規模、自動化修訂需要大量溝通協調，時程往往會拉得很長，難以有效率推行。</li>
</ul>

<p>總體而言，維基文庫的設計是以人工即時編輯為主，而我們要大量程式操作，因而不適合以之作為主要平台。話雖如此，維基文庫仍是優秀的協作系統，也收錄了大量優質文獻，若有志者願意做雙向的資料共享與整合，我們樂觀其成。</p>

<p>至於其他wiki系統，按我們過去嘗試以DokuWiki建置《笈成資料庫》的經驗，自架DokuWiki允許自訂語法，也允許私人空間，比MediaWiki靈活，但「大規模編輯」及「錯誤還原」仍有相同的困難。此外DokuWiki系統在資料量大時效能會明顯低落，過去《笈成資料庫》的資料量即有效能問題，因此也非理想。</p>
